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Design Issues in the GCF Mark IV Development 

R . A. Crowe 
DSN Data Systems Section 


This article outline * some of the major design problems facing the computer based 
BF Digital Communication System for the Mark IV Network Consolidation Program 
and discusses the solutions to each as implemented in the software of the GCF Operation 



I. Introduction 

The requirements of the Network Consolidation Program 
(NCP) (Ref. 1) mandate that the Ground Communications 
Facility (Ref. 2) be extensively upgraded in order to support 
upcoming projects in the nineteen eighties and beyond. Both 
hardware and software changes are necessary (Ref. 3). 

When the Mark IV changes are complete there will exist 
three Deep Space Communication Complexes, one at each of 
the principal sites of the DSN (Fig. 1). The SPC building at 
each DSCC will house the computers and equipment necessary 
for tracking support. More than vine mission may be simulta- 
neously supported at each complex. Deep Space Stations 
(DSS) will be configured from a set of equipment within the 
SPC along with outlying antenna. The Area Routing Assembly 
(ARA) is the GCF Computer at each SPC responsible for the 
processing of DSN Data Blocks (Fig. 2). The ARA will per- 
form transmission, reception and routing of data for all DSSs 
active at the SPC For this purpose the ARA will interface to 
2 or 3 digital communication circuits that connect the SPC 
with the Central Communications Terminal (CCT) at the Jet 
Propulsion Laboratory (JPL). One circuit will permit full 
duplex traffic both into and out of the SPC. The ARA will 
utilize it for iow rate data to JPL. The other one or two 
circuits shall be simplex circuits that will carry outbound 


traffic only. The ARA will transmit high-rate data blocks on 
these circuits. Data from all JSSs must share the available 
circuits. 

At JPL the eventual terminuses of all SPC circuits are the 
five Error Correction and Switch (ECS) computers of the CCT 
aiea (Fig. 2). A solid state di^al communication sv'itr’ ad- 
ware device shall allow flexi mty in the assignment f cc. l u 
to individual computers. The ECS computer t andle noi only 
the circuits from the AR/.s but also digital circuits to Remote 
Mission Operation Centers (RMOC), Rem »e Information Cen- 
ters (RIC) and other remote sites in the DSN. Each of the ECS 
computers “knows" the circuit assignments of the remaining 
ECS computers. A network, therefore, has been established 
here that permits ECS to ECS communication necessary for 
(remote) site to (remote) site exchange of data using the CCT 
as a central hub. 

The major problems encountered in developing the Mark IV 
GCF are summarized as follows; 

(1) The shared usage among DSSs of the duplex and multi- 
ple simplex circuits. 

(2) The necessity for “vitalizing” the data flow both at 
the SPC and at JPL. 
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(3) The difficulty at the CCT of handling both Mark 111 
and Mark IV data blocks for an extended period of 
time. 

(4) Delayed project requirements specifying that the 
ECS computers route the same data block to two 
destinations. 

(5) The retention by the ECS software of essentia! routing 
features currently supported by hardware but sched- 
uled for removal. 

E:ch of these subjects is discussed individually in the following 
paragraphs. 


II. Economy of SPC Circuit Utilization 

For the ARA softwaie implementations, th servicing of 
the duplex ciicuit to * e SPC presents no particular design 
problems. Low rate ( 1200- bit) daU blocks from each DSS will 
be multiplexed on a first-come- first-served basis. Error correc- 
tion of data blocks via retransmission in cooperation with the 
ECS will be implemented in a manner similar to the method 
used for Mark 111 stations. The servicing of two simplex cir- 
cuits to the ECS, however, does present some difficulties. How 
was the ARA to decide on which simplex channel it should 
transmit the data blocks for each DSS? The utilization of both 
circuits equally for transmission would result in blocks arriving 
out of their original sequence at the ECS. An opeiator assign- 
ment of each DSS to a particular circuit seemed laborious and 
quite inefficient since typically one circuit might be overloaded 
while the other sat idle. Operational attention to the load bal- 
ance between simplex ;rcuits would constantly be demanded. 

The soh* f *on to this problem was undertaken by utilizing 
the GCF fields of the data blocks that are normally used for 
the error correction algorithm. Since error correction is not 
performed on the simplex circuits, these fields are free for the 
assignment of an Arrival Sequence Number (ASN) by the ARA 
when the blocks arrive at the ARA and before transmission to 
the ECS. The ASN assignment of data blocks permits the ARA 
to switch them automatically to either simplex circuit as load 
conditions dictate. Out-of-sequence arrivals at the ECS are 
handled promptly by means of a short retention queue and a 
simpL .esequencing algorithm based on the ASN. 


III. Data Flow Visability 

A significant problem at ihe ARA md particularly at the 
ECS was the tracing of the data block tlow through each com- 
puter. This capacity is crucial in the verification of the new 
software and instrumental in diagnosing system problems 


when the programs are operational. The existing one-dimen- 
sional data block dump features of the Mark 111 programs were 
inadequate for the following reasons: 

(1) The formatting of data blocks was performed within 
the core storage of the computer and passed immediately 
to the line printer. Since the Mark IV data rates -re 
measurably enhanced and because the core size of the 
computers is relatively small (64 K words) the dumping 
of even a modest contiguous sample of data blocks is 
precluded 

(2) Data blocks could be dumped at only one transition 
point (e.g. Input/Output interface) of the program. In 
the case of the ECS, this was too restrictive since any 
one data block might be delivered to several local or 
remote sites. It is useful to record the passage of the 
block through each transition point of the program. 

To solve these inadequacies. f he Mark IV Programs imple- 
mented a dumping facility that ^aiizes a multifile disc spool- 
ing capability (Fig. 3). Disc storage has been partitioned into 
several spool files. Each file is available for assignment to a par- 
ticular I/O Interface or other transition point of the program. 
After I/O handling, data blocks are relayed to the Formatter 
and Spooler Task where information is extracted, converted to 
ASCII, and immediately rete' ed to the spooler disc file that is 
servicing the I/O Interface. Following this relatively fast opera- 
tion, the data blocks are released for transit through the re- 
mainder of the program. By this mechanism, since the disc 
files are relatively large ( 10 K words each), it is possible to cap- 
ture long contiguous sample* of data blocks passing through 
several I/O Interfaces simuhineously . 

The Despooler and Printer Task will print one file at a time 
at the (slow) rate of the line printer. When an end-of-file is 
detected, the despooler will initiate the printing of another 
spooler file. Blocks dumped simultaneously but to different 
spooler files may later be time correlated by comparing dump 
information from the sequential print-outs. 

IV. Transition to Mark IV 

The transition of the DSN to a Mark IV configuration was a 
particularly keen problem in t! * design of the ECS Program- 
Facing the development effort were the following known 
facts: 

(1) A network of four ECS computers, one Central Com- 
munication Monitor (CMF) computer and three Data 
Recc ds Generator (DRG) computers, were currently 
on-line to support Mark III data flow. Operations nor- 
mally operated each program from theCCM. Each pro- 
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ram was to be modified for Mark IV. A strict protocol 
governed data block exchanges among computers 

(2) The transition is not abrupt. The phasing over of the 
DSN to Mark IV will take 10 to 14 months. Therefore, 
there is an extended period of time where both Mark 
III and Mark IV data must be handled. 

(3) The set of source/de.dination codes to be used in Mark IV 
data blocks is different from the set used for Mark III. 
Newly identified Block Format Codes (BFC) placed in 
each data block allowed discrimination between Mark 111 
and Mark IV data blocks. 

(4) Removal of some CCT hardware as part of the new 
effort would jeopardize deliveries of Mark III data to 
tw o local JPL sites (VLBI/ MCC ). 

The basic question to be answered before design could pro- 
ceed was whether to retain the existing ECS during the transi- 
tion phase and create the new ECS to support Mark IV data 
only, or create the new ECS to support both Mark III and 
Mark IV data thereby retiring the current ECS. In support of 
two operational versions of the ECS were the facts that fewer 
functions would need io be lodged in the new program and 
that introduction of the new’ software would be less cata- 
strophic: Mark III support would be assured in any event. 

Balancing these considerations were the facts that: 

(1) The new software would be forced to abide by exist- 
ing protocols, operator input formats, etc. thereby 
placing a severe constraint on the free design of the 
rew program. 

(2) Operations would be forced to operate two versions of 
the ECS at the same time, thereby causing confusion 
and inevitably leading to procedural errors. 

(3) A single program would allow any Mark III/ IV mix of 
communication circuits on the same computer thereby 
optimizing computer/communication circuit utilization. 

(4) The new- CCM program w'ould not be able to communi- 
cate with the old ECS thereby causing gaps in the mon- 
itor information displayed to operations. 

For the above reasons, it was decided to incorporate the 
support of Mark III data flow within the n^w ECS program 
and have but or»e version of the ECS on-line at any given time. 
A ramification of this decision is that the new software must 
now' prove its capabilities at two different instances: the first 
will occur when the current software is replaced, well in advance 
of any Mark IV station, and the second occurs when the first 
Mark IV station is brought up for operational support and 
begins the generation of the new data blocks. 


V. Multiple Routing 

Halfway into the coding of the ECS program came the elev- 
enth hour requirement that some data blocks transmitted from 
a generating DSS would need to be routed to two different 
sites in the DSN. This was not an extant ECS capability but it 
was felt that because the DSN was gravitating toward High 
Earth Orbite; (HEO) support missions (with multiple users), 
it would be a wise inclusion in the new software. 

The design response to this requirement was to invent dumnn 
destination codes that the originating source would insert into 
data blocks when multiple routing was desired. The ECS rout- 
ing constructs . is such that the destination code from each 
block is used to index into a 256 word table corresponding to 
its field width of 8-bits. Normally, the position of the table at 
this point determines the (one) output path of the data block. 
For multiple routing destinations, however, two translation 
destination codes are inserted in the table at this point and 
flagged as such. The action of the ECS upon detection of a 
multiple destination code is to overlay the dummy destination 
code in the block with the first code from the table, and to 
store th* second destination c 1e in a data structure associated 
with the data tlocx. The block is then passed through the vari- 
ous internal ECS tasks where it is routed as specified by the 
first destination code. Following this transit, the second des- 
tination code is used to overlay the first destination code and 
the block is released for another circuit through the internal 
tasks of the ECS. 

A noteworthy feature of this capability is that operations 
may. in the future, invent dummy and associated translation 
destinations without a modification to the program as trans- 
ferred. Operatoi inputs will cause alteration of the routing 
table thereby defining the multiple routing desired and a peri- 
odic s«ve of this table to d*sc storage will permit a restart 
(Warm Start) of the software to recognize the changes. 

VI. Replacement of Hardware 
Routing Features 

The delivery of 48C0-bit Mark III data blocks to the Mission 
Control and Computing Center (MCCC) and to the Very Long 
Baseline Interferometry (VLBI) processors was implemented 
by means of a hardware switch in the CCT called the Wideband 
Distributed Amplifier (WDA) (Fig. 4). Data blocks are tapped- 
off from each of the six possible circuits and passed to the 
MCCC and VLBI organizations directly. Because each circuit 
is driven by but one computer (VLBI or MCCC Telemetry) at 
the DSS a "pure stream" of data is routed by the WDA. The 
ECS, in this case, does not route the blocks by destination 
code but does monitor the circuit and deliver the blocks to the 
DRG computers for tape records. 



In Mark IV the use of the WDS will no longer be possi- 
ble. The ARA will multiplex data from all DSSs of the SPC 
on the ava table circuits. A tap-off by the WDA will no longer 
produce a "pure stream” of data blocks. Yet because no 
resources are available to modify the MCCC or VLBI pro- 
cessors to sort through a mixture of data blocks, the ECS was 
to be burdened with routing to each delivery circuit an unadul- 
terated stream of data blocks generated by one and only 
one source (DSS)! In the Fig. 5 example, it is assumed that 
DSSs 12, 14 and 42 are all active and transmitting data to 
the CCT with the same destination code. The ECS com- 
puters are charged with sorting these data by the originating 


source and placing them in Delivery Lines (DL) 1. 2, or 3. 
respectively . 

In order to solve this organizational problem, it was decided 
to add a secondary routing table to the ECS software. An opera- 
tor would cause entries to be made in the secondary table by 
assigning each DSS to a unique Delivery Line Internally, the 
ECS would Hag the Common Destination Code so that its 
detection would cause reference to this table. The secondary 
table is then scanned for a match on Source Code and the 
block is routed as previously specified by the operator to the 
proper Delivery Line. 


References 


J. Yeater. M. L.. and Herrman. D. T.. "Networks Consolidation Program.” TDA Progress 
Report 42-65, July and August 1981, Jet Propulsion Laboratory. Pasadena. Calif. 
Oct. 15. 1981. 

2. Evans. R. H.. “DSN Ground Communications Facility." TDA Progress Report 42-65, 
July and August 1981, Jet Propulsion Laboratory. Pasadena. Calif. Oct. 15. 1981. 

3. Mortensen. L. 0.. “GCF Mark IV Development.” TDA Progress Report 42-70 , May 
and June 1982, Jet Propulsion Laboratory. Pasadena. Calif., Aug. 1 5. 1982. 


135 



ORIGINAL PAGE IS 
OF POOR QUALITY 












ORIGINAL PAGE IS 
OF POOR QUALITY 


SIGNAL PROCESSING CENTS* 


- CENTRAL COMM TERMINAL 


LAN 


i 1 



Fig. 2. Digital communications subsystem overview of GCF digital configuration 
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Fig. 3. Data block dump mechanism 
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Fig. 4. MCCC/VLBI routing in Mark III 
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Fig. 5. Mark IV ECS-MCCC wideband data routing example 
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